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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for 
Advanced Networks (SPAN). 

The present document is part 19, sub-part 1 of a multi-part deliverable covering Digital Broadband Cable Access to the 
Public Telecommunications Network; IP Multimedia Time Critical Services. Full details of the entire series can be 
found in part 1 (TS 101 909-1 [10]). 



Introduction 



The present document describes the architecture and specifies a set of signalling interfaces that may be used for playing 
announcements in voice-over-IP (VoIP) IPCablecom networks. It defines one of these interfaces: the MPC-MP 
interface. 

The ideal objective for this interface would be to have a standard based on a single technical solution. However, 
commercial implementations of the Audio Server application based on a potential candidate for such a solution, ITU-T 
Recommendation H.248 [3], cannot yet be validated against the Audio Server requirements. 

The present document defines a solution based on H.248. The solution based on ITU-T Recommendation J. 162 (see 
Bibliography) is defined in TS 101 909-19-2 [4]. 
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Scope 



The present document describes the architecture and protocols that are required for playing announcements in 
Voice-over IP (VoIP) IPCablecom networks, where the IVR (Interactive Voice Response) system is embedded in the 
IPCablecom network. Announcements are typically needed for calls that do not complete. Additionally, they may be 
used to provide enhanced information services to the caller. Different carrier service feature sets require different 
announcement sets and announcement formats. 

Announcements can be as basic as fixed-content announcements (e.g. all circuits busy) or as complex as those provided 
by intelligent IVR (Interactive Voice Response) systems. The IPCablecom service model requires that all 
announcements be provisioned and signalled in a standard manner for all supported call features and use case scenarios. 

The present document identifies a set of signalling interfaces that are used to provide announcement services within a 
cable network, and specifies one of these interfaces: the MP-MPC interface, based on the protocol defined in ITU-T 
Recommendation H.248 [3]. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

announcement: announcement to be played and which consists of one or more audio segments 

cable modem: cable modem is a layer two termination device that terminates the customer end of the J. 1 12 connection 
(ITU-T Recommendation J. 1 12) 

digit map: one or more digit patterns to be collected 

EuroPacketCable: ETSI working group project that includes an architecture and a series of Specifications that enable 
the delivery of real time services (such as telephony) over the cable television networks using cable modems 

IPCablecom: ETSI working group project that includes an architecture and a series of Specifications that enable the 
delivery of real time services (such as telephony) over the cable television networks using cable modems 

off-net(work): voice call or data transmission session in which either the originating or terminating device is connected 
to an IPCablecom network which is interconnected to another network which is supporting the second terminal 

on-net(work): voice call or data transmission session in which the originating and terminating devices are connected to 
a single IPCablecom network which may consist of one or more zones or domains 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ABNF Augmented Backus-Naurr Form 

AS Audio Server 

CMS Call Management Server 

DNS Domain Name Server 

DTMF Dual Tone Multi-Frequency 
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IKE 

IPSEC 

IVR 

MG 

MGC 

MP 

MPC 

MTA 

NCS 

PSTN 

RTP 

RTCP 

SDP 

SPI 

TGCP 

VoIP 



Internet Key Exchange 

Internet Protocol Security 

Interactive Voice Response system 

Media Gateway 

Media Gateway Controller 

Media Player 

Media Player Controller 

Media Terminal Adapter 

Network-based Call Signalling 

Public Switched Telephone Network 

Real Time Protocol 

RTP Control Protocol 

Session Description Protocol 

Security Parameter Index 

Trunking Gateway Control protocol 

Voice over IP 



Technical overview 



The IPCablecom Audio Server Specification identifies a suite of signalling protocols for providing announcement and 
media services in an IPCablecom network. This clause: 

• defines the architectural requirements for providing IPCablecom announcement and media services, 

• defines and categorizes announcement and media types, 

• defines the components and their roles in the IPCablecom Audio Server Architecture, and 

• describes the signalling and media interfaces in the IPCablecom Audio Server Specification. 



4.1 Architectural requirements 



The architectural requirements and assumptions for providing Audio and Media Services for an IPCablecom Network 
are listed below. These requirements are based upon the specifications and technical reports that define the IPCablecom 
architecture. 

The reference architecture for the IPCablecom Network (TS 101 909-2 [1]) is shown in Figure 1 below. 
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Figure 1: IPCablecom Network Component Reference Model 



4.1.1 



Call destination 



The Audio Server Specification shall define how announcements are provided for IPCablecom on-net to off-net and 
on-net to on-net calls. 

NOTE: Announcements for Off-net to on-net calls will usually be handled by the PSTN as a result of SS7 

clearing messages. However when appropriate, they also may be played from the IPCablecom Media 
Gateway (MG). 

4.1.2 Media formats 

The required media formats for announcements are specified by the IPCablecom Codecs specification 
(TS 101 909-3 [6]). 

4.1.3 Security 

Audio shall be signalled and played in a secure manner. Security protocols defined in the IPCablecom Security 
specification TS 101 909-1 1 [7] shall be supported in the IPCablecom Audio Server Specification. 

4.1 .4 Operational Support Systems 

Audio Servers may be required to support the IPCablecom billing and event message protocols as defined in [8]. 

4.2 Announcement definitions 

Announcements can be divided into four distinct categories: tones, fixed-content, variable content, and interactive 
announcements. 
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4.2.1 Tones 

Includes tones such as reorder, busy, and ringback. See [9] for further examples. 

4.2.2 Fixed-content Announcements 

Fixed-content Announcements consist of audio messages with fixed-content that require no user interaction. For 
example, "Your call did not go through. Please hang up and try your call again.". 

4.2.3 Variable Content Announcements 

Variable Content Announcements are messages that contain a customizing parameter(s) yet require no user interaction. 
For example, "The number you have dialled, 32 19 876, has been changed. The new number is 32 16 789.". 

4.2.4 Interactive Announcements 

Interactive Announcements are announcements that require user interaction, DTMF (Dual Tone Multi-Frequency) or 
IVR. For example, "The number you have dialled, 54 13 2198 76, has been changed. The new number is 54 13 2167 89. 
To be connected to the new number, at a cost of thirty-five cents, please press 1.". 



4.3 Architectural components 



IPCablecom components responsible for providing announcement services are defined below. These components work 
together to provide the complete set of announcement services available from the IPCablecom network provider. There 
may be more than one of these components in the network. Figure 2 defines a logical architecture for providing 
announcement services and only where an interface is exposed is it expected to meet IPCablecom specification 
requirements. 

4.3.1 Audio Server (AS) 

An AS is a logical entity composed of a Media Player Controller (MPC) and a Media Player (MP). 

4.3.1 .1 Media Player Controller (MPC) 

The MPC initiates and manages all announcement services provided by the Media Player. The MPC accepts requests 
from the CMS and arranges for the MP to provide the announcement in the appropriate stream so that the user hears the 
announcement. The MPC also serves as the termination for certain calls routed to it for IVR services. These might 
include, for example, calls in which the user dials an <free phone> number to reach a credit-card calling service 
operated by the IPCablecom network operator. When the MP collects information from the end-user, the MPC is 
responsible for interpreting this information and manage the IVR session accordingly. Hence, the MPC will manage call 
state. 

The MPC can be standalone, or it can be embedded within the CMS. See Figure 2 and Figure 3 for illustrations of 
standalone and embedded MPC configurations. 

4.3.1.2 Media Player (MP) 

The Media Player is a media resource server. It is responsible for receiving and interpreting commands from the MPC 
and for delivering the appropriate announcement(s) to the MTA. The MP provides the media streams with the 
announcement contents. The MP also is responsible for accepting and reporting user inputs (e.g. DTMF tones). The MP 
functions under the control of the MPC. 

An MP can be standalone, or it can be embedded with the MPC in a Media Server. See Figure 2 and Figure 4 for 
respective illustrations of the stand-alone and embedded MP configurations. 
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4.3.2 Multimedia Terminal Adapter (MTA) 

The MTA has the ability to provide tones and a limited set of fixed-content announcements to the user. The MTA 
accepts NCS signalling requests from the CMS and plays the appropriate tones and announcements accordingly. 

4.3.3 Media Gateway (MG) 

The Media Gateway to the PSTN also has the ability to provide fixed-content announcements to PSTN end-users 
involved in off-net to on-net calls. The MG accepts TGCP request to play announcement from the Media Gateway 
Controller (MGC) and provides the announcements accordingly. 

4.3.4 Media Gateway Controller (MGC) 

The Media Gateway Controller (MGC) receives and mediates call-signalling information between the EuroPacketCable 
network and the PSTN. It also has the ability to request the MG to play announcements. 

4.3.5 Call Management Server (CMS) 

The CMS determines when announcements should be played at the MTA, when to use the resources of a network 
MPC/MP complex, and when to play announcements to a PSTN end-user from the MG. This is based on the status of a 
call in progress. The CMS then signals the appropriate entity: MTA, MPC, or MGC to play tones or announcements to 
the end-user, accordingly. 

4.4 IPCablecom Audio Server Interface descriptions 

The signalling interfaces to support Media Services are shown in Figure 2 and are summarized in Table 1 . 

Table 1 : Announcement Interfaces 



Interface 


Signalling Components 


Protocol 


Ann-1 


MTA/CMS, MGC/MG 


NCS/TGCP with announcement 
packages 


Ann-2 


MPC/MP 


The present document. 


Ann-3 


CMS/MPC, CMS/MGC 


Undefined. See clause 4.4.3. 


Ann-4 


MP/MTA 


RTP 



The remainder of this clause provides an overview of the announcements interfaces introduced above. 

4.4.1 Ann-1 Interface - CMS/MTA and MGC/MG Announcement package 

The IPCablecom Network Call Signalling (NCS) protocol and the IPCablecom Trunking Gateway Protocol (TGCP) 
include an announcement package that can be used for the CMS-MTA and MGC-MG interfaces. 



4.4.1.1 



CMS/MTA Interface 



The CMS to MTA interface provides a mechanism for the CMS to signal the MTA to play locally stored 
announcements. Simple tones and some frequently used fixed-content announcements (e.g. network busy) may be 
stored in the MTA so they can be played to the IPCablecom subscriber without tying up network bandwidth or media 
resources. Furthermore, storing these announcements in the MTA allows for providing informative progress tones to the 
end user independently of the Network State (e.g. congestion). 



4.4.1.2 



MGC/MG Interface 



The MGC to MG interface provides a mechanism for the MG to play fixed-content announcements to PSTN end-users 
involved in off-net to on-net calls. For example, MG announcements may be used to provide PSTN users call progress 
information for calls that cannot be completed to the IPCablecom network (all-lines-busy). Simple, fixed-content 
announcements (e.g. all-lines-busy) may be stored at the Media Gateway to provide announcements to PSTN users. 
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4.4.2 Ann-2 interface - MPC/MP Announcement package 

The MPC to MP protocol is based upon ITU-T Recommendation H.248 [3] and the packages defined in Annex M.l of 
ITU-T Recommendation H.248 (see Bibliography). Less frequently used tones and fixed-content announcements, as 
well as all variable content and interactive announcements are provided by MPC and MP complex. With regards to the 
H.248 protocol architecture, the MPC plays the role of an MGC, while the MP plays the role of an MG. 

When the CMS identifies a need for an AS -based announcement, it sends a request to the MPC over interface Ann-3. 
Upon receiving a request from the CMS, the MPC opens a session with the Media Player . The MP then interacts with 
the specified endpoint over interface Ann-4. 

4.4.3 Ann-3 interface - CMS/MPC and CMS/MGC 

The Ann-3 interface allows the CMS to request the MPC to establish announcement sessions between the MP and 
another endpoint. It also allows the CMS to request the MGC to have the MG play fixed-content announcements to a 
PSTN endpoint. This interface is currently undefined. It is expected that this signalling interface will be based upon the 
IPCablecom CMS/CMS signalling protocol being specified in TS 101 909-16 (see Bibliography). The protocol for the 
Ann-3 is for further study. 

4.4.4 Ann-4 interface - MP/MTA 

The interface Ann-4 defines the media stream format (RTP) for delivery of the announcement from the ANP to the 
MTA. The specifics of interface Ann-4 are not within the scope of the present document. 

4.4.5 Audio Server Physical vs. Logical configuration 

It should be noted that the MPC and MP are logical components that may reside in the same physical entities. When 
logical components reside in the same physical entity, interfaces between these components are not exposed and 
become unspecified. 

It should also be noted that standalone components using the Ann-2 and Ann-3 interfaces specified in the present 
document may be shared by many network entities. 

Figure 2 depicts an example of a network where the CMS, MPC, and MP are implemented as separate physical entities 
communicating over the Ann-2 and Ann-3 interfaces. 



Ann-3 
Interface 




Ann-1 
Interface 



MTA 



Ann-2 
Interface 



Ann-4 Media 
stream 



Ann-2 
Interface 



Ann-2 
Interface 



Media Player 



Media Player 



Figure 2: Standalone Components configuration 

The MPC may be embedded with the CMS, as shown in Figure 3. In this case, interface Ann-3 is not exposed and 
becomes unspecified. 
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Figure 3: Embedded MPC configuration 

Similarly, the MP may be embedded with the MPC, as shown in Figure 4, in which case the interface Ann-2 is not 
exposed and becomes unspecified. 




Ann-1 
Interface 



MTA 



Ann-3 



Ann-4 Media stream 



Media Player 
Controller 



Embedded 
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Figure 4: Embedded MP configuration 

Finally, the CMS and AS, (MPC and MP) may be embedded in the same physical entity, in which case the Ann-2 and 
Ann-3 interfaces are not exposed and become unspecified. 
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Figure 5: Embedded AS configuration 



4.5 Interface Specifications 



The IPCablecom Audio Server Specification identifies a set of interfaces between the components responsible for 
providing audio services. The following figure illustrates the interfaces between these components. Only where an 
interface is exposed is it expected to meet IPCablecom specification requirements. 
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Figure 6: IPCablecom Audio Server Components and Interfaces 



5 Ann-1 interface: CMS-MTA and MGC-MG 

The CMS-MTA and MGC-MG announcement interfaces are implemented by the Legacy Audio Package of the 
NCS/TGCP protocol, which provides the playback of tones and fixed-content announcements to the end-users. 



5.1 



CMS-MTA Interface 



Each MTA in the network may store a predefined set of simple announcements locally. When an announcement is 
needed, the CMS will decide if it should instruct the MTA to play a local announcement or set up a connection between 
the MTA and a Network ANS and have the announcement played over the network. Playing simple announcements 
from the MTA saves network resources. 

The MTA may store announcements in either static or dynamic memory. If announcements are stored in dynamic 
memory then the announcements will not be available until the MTA has accessed them from the network. 

For example, these simple announcements will require only a small amount of storage on the MTA. The table below 
illustrates the storage requirements for such announcements. The example uses an average announcement time of 
10 seconds. 
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Table 2: ANS Storage 



Number of 
Announcements 


Announcement 
Length (seconds) 


Encoding bytes/second 


Bytes required 


11 


10 


2 000 (ITU-T Recommendation G.728 [14]) 


220 kbytes 


11 


10 


8 000 (PCMU/PCMA) 


880 kbytes 



MTAs require the ability to be updated dynamically with announcements so that the same MTA can move from service 
provider to service provider without requiring complete firmware upgrades. This capability is for further study. 

5.1.1 Announcement list 

The table below lists the text version of the announcements that should be stored locally on the MTA. Each MTA is 
required to store and play announcements similar to those defined in the following table. Announcements that address at 
least the following network conditions may be played using the announcement package of the NCS protocol. Cached 
versions of all announcement should be refreshed every time the MTA connects to the network. Other methods of 
propagating new announcements to MTAs, for instance while the MTA remains in service, is an issue for study by the 
provisioning team and is beyond the scope of the present document. 

Table 3: Sample announcements 



Sample Announcement 


Name 


Your call cannot be completed as dialled. Please check 
the number dialled and try again. 


Vacant Code (cf. ITU-T Recommendation E.182 [13]) 


Please replace the receiver and try again. If you need 
help, replace the receiver and dial the operator. 


Re-order time-out (cf. ITU-T Recommendation E.182 [13]) 


Your call cannot be completed as dialled. Please read 
the instruction card or call your operator for assistance. 


Assisted Dialling (cf. ITU-T Recommendation E.182 [13]) 


Your call cannot be completed at this time. Please try 
your call again. 


Reorder (cf. ITU-T Recommendation E.182 [13]) 


The network is busy at the moment. Please try your call 
later. 


No Circuit (cf. ITU-T Recommendation E.182 [13]) 


The called number is not obtainable because of a 
network fault. Please try your call later. 


Domestic Facility (cf. ITU-T Recommendation E.182 [13]) 


The party you are calling has declined to receive this 
call. Please try your call again with "Calling Line 
Identity" enabled. 


Unidentified Call Reject 


Thank you for using [carrier's name] 


Branding (N/A in EU). 



5.2 



MGC-MG Interface 



The MG announcement interface (Ann-1) allows for the MGC to request the MG play fixed-content announcements to 
PSTN end-users. The MGC/MG announcement interface package does not specify any standard announcements to be 
stored locally in the MG. All announcements are provisioned dynamically and are referenced accordingly. 

This MG announcement provisioning capability is for further study. 



Ann-2 interface: MPC-MP 



An MP (Media Player) is a shared resource in the IPCablecom Network that can be instructed to provide media services 
to an end-user or terminal. These services include streaming fixed-content, variable content and interactive 
announcements to IPCablecom subscribers. For example, the MP is responsible for playing prompts and collecting 
digits when charging a call to a calling card. 

The MP is controlled by an external element, the MPC (Media Player Controller). The MP is responsible for managing 
its own resources. When accepting a request, the MP SHALL make sure that the required resources are available before 
accepting request. When a single session involves multiple requests to the Media Player, the MP may experience a 
shortage of resources preventing it from accepting one given request belonging to that session. In this case, the MP user 
(i.e. the MPC) is responsible for re-sending the request or terminating the end-user session elegantly. 
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The ANN-2 interface shall be implemented as an H.248 profile described in the following clauses. 

This profile shall be entitled "IPCablecom Audio Server". The version number shall be 1.0. This name shall be returned 
by conforming media players when sending a ServiceChange command as part of the initial registration of the MP. 

6.1 Support of packages 
6.1.1 Mandatory packages 

The following packages SHALL be supported: 



Package Name 


Id 


Version 


Defined in 


Generic 


g 




ITU Recommendation H.248 [3] Annex E 


Base Root 


root 




ITU Recommendation H.248 [3] Annex E 


Network 


nt 




ITU Recommendation H.248 [3] Annex E 


Advanced Audio Server 


aas 




ITU Recommendation H.248 Annex M.1 (see Bibliography) 


AAS Digit Collection 


aasdc 




ITU Recommendation H.248 Annex M.1 (see Bibliography) 



6.1.2 Optional packages 

The following packages MAY be supported: 



Package Name 




Version 


Defined in 


AAS Recording Package 


aasrec 


1 


ITU Recommendation H.248 Annex M.1 (see Bibliography) 


AAS segment management 


aassm 


1 


ITU Recommendation H.248 Annex M.1 (see Bibliography) 


Security 


sec 


1 


TS101 909-13 [2] 



NOTE: The packages defined in ITU-T Recommendation H.248 Annex M.1 (see Bibliography) have been 

organized in a modular way, which makes possible to implement all the packages or only those which are 
required to support the most common features (i.e. playing announcements and collecting digits). 



6.2 Compatibility rules 



This profile is based on ITU-T Recommendation H.248 [3], The compatibility rules for packages, signals, events, 
properties and statistics and the H.248 protocol are defined in ITU-T Recommendation H.248 [3]. 



6.3 Naming conventions 



MP and MPC names shall be in the form of a domain name. An example MPC name is: 

mpc 1 . whatever, net 
Reliability is provided by the following precautions: 

• MPs and MPCs are identified by their domain name, not their network addresses. Several addresses can be 
associated with a domain name. If a command cannot be forwarded to one of the network addresses, 
implementations SHALL retry the transmission using another address. 

• MPs and MPCs may move to another platform. The association between a logical name (domain name) and the 
actual platform are kept in the Domain Name Service (DNS). MP and MPC SHALL keep track of the record's 
time-to-live read from the DNS. They SHALL query the DNS to refresh the information if the time-to-live has 
expired. 



6.4 Topology descriptor 



A Media Player conforming to this specification need not to implement Topology. MPCs that expect control gateway 
conforming to this specification shall not assume that Topology is supported. 
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6.5 Transaction timers 

All transaction timers as specified in ITU-T Recommendation H.248 [3] shall be supported here. 

6.6 Transport 

Media Players SHALL implement UDP/ALF. 

Media Player Controllers SHALL implement UDP/ALF. 

6.7 Service change procedures 

The Media Player shall allow one primary and one or more secondary Media Player Controller to be provisioned for 
registration. 

6.8 Security 

Media Players and Media Player Controllers SHALL implement IPsec (RFC 2401 [20]) and SHALL use IKE 
(RFC 2409 [21]) for key management. 

6.9 Encoding 

Conforming Media Players SHALL support text encoding. 

6.10 UseofSDP 

Strict conformance to RFC 2327 [15] is required. However, MPs and MPCs may make certain simplifying assumptions 
about the session description as specified in the following. 

SDP usage depends on the type of session, as specified in the "media" parameter. This Technical Specification only 
support media of type "audio". 

The SDP profile provided describes the use of the session description protocol on the MP-MPC interface. The general 
description and explanation of the individual parameters can be found in RFC 2327 [15], however below we detail what 
values MPs and MPCs need to provide for these fields (send) and what MPs and MPCs should do with values supplied 
or not supplied for these fields (receive). 

Any parameter not specified below SHOULD NOT be provided by any MP or MPC, and if such a parameter is 
received, it SHOULD be ignored. 



6.10.1 Protocol version (v=) 



v= <version> 


v= 


Send: 


Receive: 



SHALL be provided in accordance with RFC 2327 (i.e. v=0) 
SHALL be provided in accordance with RFC 2327. 

6.10.2 Origin (o=) 

The origin field consists (o=) of 6 sub-fields in RFC 2327 [15]: 

0= <username> <session-ID> <version> <network-type> <address-type> <address> 
o= - 2987933615 2987933615 IN IP4 A3C47F2146789F0 
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Username: 

Send: 

otherwise. 

Receive: 

Session-ID: 

Send: 

clients. 

Receive: 

Version: 

Send: 

Receive: 

Network Type: 

Send: 

Receive: 

Address Type: 

Send: 

Receive: 

Address: 

Send: 

clients. 

Receive: 



Hyphen SHALL be used as username when privacy is requested. Hyphen SHOULD be used 
This field SHOULD be ignored. 

SHALL be in accordance with RFC 2327 for interoperability with non-EuroPacketCable 
This field SHOULD be ignored. 

In accordance with RFC 2327. 
This field SHOULD be ignored. 

Type "IN" SHALL be used. 
This field SHOULD be ignored. 

Type "IP4" SHALL be used. 
This field SHOULD be ignored. 

SHALL be in accordance with RFC 2327 for interoperability with non-EuroPacketCable 
This field SHALL be ignored. 



6.10.3 Session name (s=) 



s= <sessxon-name> 



Send: 
Receive: 



Hyphen SHALL be used as Session name. 
This field SHALL be ignored. 



6.10.4 Session and media information (i=) 

i= <session-description> 

Send: This field SHALL NOT be used. 

Receive: This field SHALL be ignored. 

6.10.5 URI(u=) 

u= <URI> 

Send: This field SHALL NOT be used. 

Receive: This field SHALL be ignored. 
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6.1 0.6 E-mail address and phone number (e=, p=) 



e= <e-mail-address> 
p= <phone-number> 



Send: 
Receive: 



This field SHALL NOT be used. 
This field SHALL be ignored. 



6.10.7 Connection data (c=) 

The connection data consists of 3 sub-fields: 

c= <network-type> <address-type> <connection-address> 
c= IN IP4 10.10.111.11 



Network Type: 

Send: 

Receive: 

Address Type: 

Send: 

Receive: 

Connection Address: 

Send: 



Receive: 



Type "IN" SHALL be used. 
Type "IN" SHALL be present. 

Type "IP4" SHALL be used. 
Type "IP4" SHALL be present. 



This field SHALL be filled with a unicast IP address at which the application will receive the 
media stream. Thus a TTL value SHALL NOT be present and a "number of addresses" value 
SHALL NOT be present. The field SHALL NOT be filled with a fully-qualified domain name 
instead of an IP address. A non-zero address specifies both the send and receive address for the 
media stream(s) it covers. 

A unicast IP address or a fully qualified domain name SHALL be present. A non-zero address 
specifies both the send and receive address for the media stream(s) it covers. 



6.10.8 Bandwidth (b=) 



b= <modifier> : <bandwidth-value> 
b= AS : 64 



Send: 



Receive: 



Bandwidth information is optional in SDP but it SHOULD always be included. When an 
rtpmap or a non codec not identified in TS 101 909-03 is used, the bandwidth information 
SHALL be used. 

Bandwidth information SHOULD be included. If a bandwidth modifier is not included, the 
receiver SHALL assume reasonable default bandwidth values for well-known codecs. 



Modifier: 

Send: Type "AS" SHALL be used. 
Receive: Type "AS" SHALL be present. 
Bandwidth Value: 



Send: 
Receive: 



The field SHALL be filled with the Maximum Bandwidth requirement of the Media stream in 
kilobits per second. 

The maximum bandwidth requirement of the media stream in kilobits per second SHALL be 
present. 
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6.10.9 Time, repeat times and time zones (t=, r=, z=) 

t= <start-time> <stop-time> 

t= 36124033 

r= <repeat-interval> <active-duration> <list-of-of f sets-f rom-start-time> 

z= <adjustment-time> <offset> 



Send: 



Time SHALL be present; start time MAY be zero, but SHOULD be the current time, and stop 
time SHOULD be zero. Repeat Times, and Time Zones SHOULD NOT be used, if they are 
used it should be in accordance with RFC 2327. 



Receive: 



If any of these fields are present, they SHOULD be ignored. 



6.10.10 Encryption keys 

k= <method> 

k= <method> : <encryption-keys> 

Security services for EuroPacketCable are to be defined by the EuroPacketCable Security specification. The security 
services specified for RTP and RTCP do not comply with those of RFC 1889 [16], RFC 1890 [17], and RFC 2327 [15]. 
In the interest of interoperability with non-EuroPacketCable devices, the "k" parameter will therefore not be used to 
convey security parameters. 



Send: 



SHALL NOT be used. 



Receive: 



This field SHOULD be ignored. 



6.10.11 Attributes (a=) 



Send: 



Receive: 



<attribute> : <value> 

rtpmap : <payload type> <encoding name>/<clock rate> [/<encoding parameters>] 

rtpmap : PCMU / 8000 

X-pc-codecs : <alternative 1> <alternative 2> ... 

X-pc-secret: <method> : <encryption key> 

X-pc-csuites-rtp : <alternative 1> <alternative 2> ... 

X-pc-csuites-rtcp : <alternative 1> <alternative 2> ... 

X-pc-spi-rtcp : <value> 

X-pc-bridge : <number-ports> 
<attribute> 
recvonly 
sendrecv 
sendonly 
ptime 

One or more of the "a" attribute lines specified below MAY be included. An attribute line not 
specified below SHOULD NOT be used. 

One or more of the "a" attribute lines specified below MAY be included and SHALL be acted 



upon accordingly, 
ignored. 



'a" attribute lines not specified below may be present but SHALL be 



rtpmap: 
Send: 

Receive: 

X-pc-codecs: 
Send: 



Receive: 



When used, the field SHALL be used in accordance with RFC 2327. It MAY be used for well- 
known as well as well as non well-known codecs. The encoding names used are provided in a 
separate EuroPacketCable specification. 

The field SHALL be used in accordance with RFC 2327. 



The field contains a list of alternative codecs that the endpoint is capable of using for this 
connection. The list is ordered by decreasing degree of preference, i.e. the most preferred 
alternative codec is the first one in the list. A codec is encoded similarly to "encoding name" in 
rtpmap. 

Conveys a list of codecs that the remote endpoint is capable of using for this connection. The 
codecs SHALL NOT be used until signalled through a media (m=) line. 
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X-pc-secret: 
Send: 



Receive: 

X-pc-csuites-rtp: 
X-pc-csuites -rtcp : 

Send: 



Receive: 

X-pc-spi-rtcp: 
Send: 

Receive: 

X-pc-bridge: 

Send: 

Receive: 

recvonly: 

Send: 

Receive: 



The field contains an end-to-end secret to be used for RTP and RTCP security. The secret is 
encoded similarly to the encryption key (k=) parameter of RFC 2327 with the following 
constraints: 

• The encryption key SHALL NOT contain a ciphersuite, only a passphrase. 

• The <method> specifying the encoding of the pass-phrase SHALL be either "clear" or 
"base64" as defined in RFC 2045, except for the maximum line length which is not 
specified here. The method "clear" SHALL NOT be used if the secret contains any 
characters that are prohibited in SDP. 

Conveys the end-to-end secret to be used for RTP and RTCP security. 



The field contains a list of ciphersuites that the endpoint is capable of using for this connection 
(respectively RTP and RTCP). The first ciphersuite listed is what the endpoint is currently 
expecting to use. Any remaining ciphersuites in the list represent alternatives ordered by 
decreasing degree of preference, i.e. the most preferred alternative ciphersuite is the second one 
in the list. A ciphersuite is encoded as specified below: 

ciphersuite = [AuthenticationAlgorithm] "/" [EncryptionAlgorithm] 

AuthenticationAlgorithm = 1*( ALPHA / DIGIT / "-" / "_" ) 

EncryptionAlgorithm = 1 *( ALPHA / DIGIT / "-" / "_" ) 

where ALPHA, and DIGIT are defined in RFC 2234. Whitespaces are not allowed within a 
ciphersuite. The following example illustrates the use of ciphersuite: 

62/51 

The actual list of ciphersuites to be provided in the EuroPacketCable Security Specification. 

Conveys a list of ciphersuites that the remote endpoint is capable of using for this connection. 
Any other ciphersuite than the first in the list cannot be used until signalled through a new 
ciphersuite line with the desired ciphersuite listed first. 



The field contains the IPSEC Security Parameter Index (SPI) to be used when sending RTCP 
packets to the endpoint for the media stream in question. The SPI is a 32-bit identifier encoded 
as a string of up to 8 hex characters. The field SHALL be supplied when RTCP security is 
used. 

Conveys the IPSEC SPI to be used when sending RTCP packets over IPSEC. The field 
SHALL be present when RTCP security is used. 



MPCs and MPss SHALL NOT use this attribute. 
MPCs and MPs SHALL ignore this attribute if received. 

The field SHALL be used in accordance with RFC 2543. 
The field SHALL be used in accordance with RFC 2543. 
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sendrecv: 

Send: 

Receive: 

sendonly: 

Send: 

Receive: 

ptime: 
Send: 

Receive: 



The field SHALL be used in accordance with RFC 2543. 
The field SHALL be used in accordance with RFC 2543. 



The field SHALL be used in accordance with RFC 2543, except that the IP address and port 
number SHALL NOT be zeroed. 

The field SHALL be used in accordance with RFC 2543. 



The ptime SHOULD always be provided and when used it SHALL be used in accordance with 
RFC 2327. When an rtpmap or non well-known codec is used, the ptime SHALL be provided. 

The field SHALL be used in accordance with RFC 2327. When "ptime" is present, the MTA 
SHALL use the ptime in the calculation of QoS reservations. If "ptime" is not present, the 
MTA SHALL assume reasonable default values for well-known codecs. 



6.10.12 Media Announcements (m=) 

Media Announcements (m=) consists of 3 sub-fields: 

M= <media> <port> <transport> <format> 
M= audio 345 6 RTP/AVP 



Media: 

Send: 

Receive: 

Port: 

Send: 

Receive: 

Transport: 

Send: 

Receive: 

Media Formats: 

Send: 

Receive: 



The "audio" media type SHALL be used. 
The type received SHALL be "audio". 



SHALL be filled in accordance with RFC 2327. The port specified is the receive port, 
regardless of whether the stream is unidirectional or bi-directional. The sending port may be 
different. 

SHALL be used in accordance with RFC 2327. The port specified is the receive port. The 
sending port may be different. 



The transport protocol "RTP/AVP" SHALL be used. 
The transport protocol SHALL be "RTP/AVP". 

Appropriate media type as defined in RFC 2327 SHALL be used. 
In accordance with RFC 2327. 



6.11 Timestamps 



Media Players are not required to include timestamps in every Notify command. 



6.12 Digits Maps 



Media Players are required to support Digit Maps, according to ITU-T Recommendation H.248 Annex M.l (see 
Bibliography). 
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